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ABSTRACT 

This paper describes a software system (ONAV) 
under development at NASA's Johnson Space 
Center in Houston for use in enhancing operational 
performance as well as training ground controllers in 
monitoring onboard Space Shuttle navigation 
sensors. Previous expert system development work at 
NASA Johnson has shown that mainstream expert 
system development must follow a mix of software 
and system engineering procedures to insure 
operational success and effectiveness. ONAV 
development reflects this trend toward following a 
structured and methodical approach to development. 
The ONAV system must deal with integrated con- 
ventional and expert system software, complex 
interfaces, and implementation limitations due to the 
target operational environment. An overview of the 
onboard navigation sensor monitoring function is 
presented, along with a description of guidelines 
driving the development effort, requirements that the 
system must meet, current progress, and future efforts. 

INTRODUCTION 

This paper describes a Onboard Navigation (ONAV) 
software system under development at NASA's 
Johnson Space Center (JSC) for use in enhancing 
operational performance as well as training ground 
controllers in monitoring onboard Space Shuttle 
navigation sensors. Previous expert system 
development work at NASA JSC has shown that 
mainstream expert system development must follow a 
mix of software and system engineering procedures 
to ensure operational success and effectiveness. 
ONAV expert system development reflects this trend 
toward following a structured and methodical 
approach to development. The ONAV system must 
deal with integrated conventional and expert system 
software, complex interfaces, and implementation 
limitations due to the target operational environment. 
An overview of the onboard navigation sensor 
monitoring function is presented, along with a 
description of guidelines driving the development 
effort, requirements that the system must meet, current 
progress, and future efforts. 


The Guidance and Onboard Navigation section 
(DM34) has a requirement to develop an ex- 
pert/trainer system to assist in the training of Mission 
Control Center (MCC) onboard ONAV console 
operators during periods other than integrated 
simulations. This system is expected to evolve into a 
console assistant with the potential for increasing 
operations support effectiveness. The Space Shuttle 
Orbiter ONAV system is relatively stable and mature 
with limited new design/developments anticipated. 
The ONAV expert/trainer involves numerous aspects 
of current and future MCC functional elements 
including workstations, local area network (LAN) 
interfaces, telemetry (systems) and ground (trajectory) 
data, and crew and ground procedures. This situation 
ensures that the ONAV expert/trainer system, 
providing experience with a majority of the aspects of 
anticipated MCC functions, will benefit future Space 
Transportation System (STS) and Space Station 
operations. 

ONBOARD SPACE SHUTTLE NAVIGATION 

The purpose of the ONAV system is to estimate the 
Space Shuttle Orbiter’s position and velocity (called 
the state vector). This is done by computing or 
measuring vehicle acceleration and numerically 
integrating it to obtain velocity and position. At various 
times, position measurements from outside sources 
are used to improve the state vector estimate. 

During the descent phase of Space Shuttle flight 
where the vehicle comes from Earth orbit down to a 
landing site, the navigation system uses several 
position measurements to improve position estimates. 
Drag altitude is a very rough measurement which 
uses inertial measurement unit (IMU) sensed 
acceleration and an atmosphere model to estimate 
the altitude. Tactical air navigation (TACAN) mea- 
sures the slant range and magnetic bearing from a 
ground station to the Orbiter. The air data system uses 
air pressure probes to measure the static atmospheric 
pressure, and compute an altitude measurement 
called baro altitude. Finally, the microwave scan 
beam landing system (MSBLS) provides measure- 
ments of slant range, azimuth angles, and elevation 
angles from ground transmitter stations located near a 
runway. 
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To achieve some degree of fault tolerance, the Orbiter 
contains three redundant IMUs, three TACAN 
transceivers, four air data sensors, and three MSBLS 
transceivers. Each piece of hardware is called a line 
replaceable unit (LRU). For each of these hardware 
systems there is a redundancy management (RM) 
software program in the onboard Shuttle computers. 
The RM has the task of choosing one set of 
measurements from the available sources and 
detecting and isolating failures in the hardware. 

THE ONBOARD NAVIGATION CONSOLE 
TASK 

The job of the ONAV console monitor is to assess the 
health of the various components of the ONAV 
system, and recommend actions to improve or 
maintain navigation accuracy. In performing this task, 
at entry ONAV uses onboard navigation data 
telemetered to the MCC, and the "ground state" (an 
independent estimate of the orbiter state.) The ground 
state is computed using ground radar measurements. 
IMU monitoring is based on comparisons of IMU 
attitude and velocity data, as well as comparisons 
with ground computed values. Possible 
recommendations include deselecting or reselecting 
IMUs. TACAN monitoring is based largely on 
comparisons of LRU measurements with the ground 
and with each other. Possible recommendations 
include using or not using TACAN data, deselecting 
or reselecting a TACAN LRU, or switching to a differ- 
ent TACAN station. ONAV has very little visibility into 
the air data system, so comparison of the baro altitude 
measurements with the ground is the main monitoring 
tool. Possible recommendations include using or not 
using baro altitude data. MSBLS monitoring is based 
on comparisons of LRU measurements with the 
ground and with each other. Possible recom- 
mendations include forcing TACAN to override 
MSBLS, or powering off a MSBLS LRU. 

DEVELOPMENT GUIDELINES 

This section presents a brief description of the 
development guidelines that impact the ONAV expert 
system. 

Problem Domain 

The ONAV expert system will consist of four distinct 
components corresponding to the following four 
Shuttle mission phases: ascent, onorbit, deorbit, and 
entry. 

Knowledge Base 

Development of the rules for the ONAV system will be 
generated and documented as four separate 
knowledge bases corresponding to each mission 
phase. The expert system will incorporate the concept 
of modular design to logically partition both data and 
rules in order to promote and enhance program 
development and extensibility. The following sources 
of information will be utilized, as appropriate for ex- 


pert system knowledge base development: ONAV 
console checklists, ONAV display user's guides, and 
ONAV console personnel. 

Development Environment 

The expert system application software will be 
executable in a language available in a workstation 
environment. However, an expert system shell written 
in C called CLIPS will be used. 

Documentation 

a) Expert system software code: The expert 
system software will include comment text, to 
the maximum extent practical, according to 
proposed documentation standards for expert 
systems being developed at the JSC. Further, 
the comments will be enhanced through the 
use of long, descriptive variable names, labels, 
etc. 

b) Guidelines and system requirements: This 
document is a top level overview of the ONAV 
development effort. This information is critical 
to providing proper direction to the project. 
Availability of this information not only provides 
a means to communicate to others not involved 
in the project, but also serves as a historical 
document. For very complex and detailed 
efforts, such a document serves as the first step 
in maintaining traceability and configuration 
control of software products. 

c) Knowledge requirements: The target audience 
for this document is the knowledge domain 
expert. It is a reflection of "what the system 
knows" in a form as close as possible to the 
expert's language. 

d) Design: This document is intended for use by 
the implementers of the expert system and will 
serve as a guide for the coding effort. Contents 
will include such things as fact formats, data 
representation, rule groupings, control flow, 
execution flow, interfaces, etc. 

e) User’s guide: The user's guide will present 
procedures for preparation, operation, 
monitoring, and recovery of the expert system. 
The user's guide will be based upon the 
design specification and is intended for the 
specific use of the users. It will include 
procedures for system operation directly in 
support of operational tasks. 

f) Test plan: The test plan defines the total scope 
of the testing to be performed. It identifies the 
particular levels of testing and describes the 
contributing role for ensuring the reliability and 
acceptance of the system. It identifies the 
degree of testing and the specific functions that 
are involved in the tests. The test plan is for 
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reviewing and ensuring that the technical 
requirements are met. 

Operation Modes 

The ONAV expert system will operate in either of two 
modes. In the first mode, referred to as "closed loop," 
the system will be used with operational data. The 
operations environment will consist of integrated 
simulations. When the expert system is certified as 
accurate and reliable, it will be used in the actual 
mission environment. In the second mode, referred to 
as "open loop," the system will be used for initial level 
training and familiarization purposes using existing 
data tapes from several sources. 

Timing 

The expert system will provide outputs in a real-time 
telemetry/trajectory environment and system timing 
will be structured accordingly. Real-time data rates 
will apply to the expert system as ported to the 
workstation environment and not apply to 
development machines, if different. The expert system 
will assume data is available at approximately 2 
second intervals. 

Display Definitions 

The primary function of the display will be to depict 
recommendations from the ONAV expert system to a 
ground controller. The goal is to provide an easily 
interpreted, quick-look format that shows the current 
status of the overall system, the status of individual 
subsystems, and recommended navigation system 
actions. 

DESIGN OVERVIEW 

The overall environment in which the ONAV expert 
system will operate is illustrated in figure 1. Although 
different mission phases may have different 
functional structures, as an example, the ENTRY 
architecture for the expert system is depicted in figure 
2. This structure results from the basic nature of the 
ONAV task at the descent phase of the mission. Four 
functional components of the expert system are 
identified: 1) fact assertion, 2) monitoring, 3) analysis, 
and 4) output. In addition, two non-expert system 
components which are a part of the overall ONAV 
system called "computations" and "data preparation" 
are also shown in both figures. The computations 
component receives information from the operational 
environment of the MCC LAN and performs various 
computations such as scaling, state vector 
propagation, coordinate system transformations, etc. 
The prime purpose is to make information uniform in 
time (i.e., homogeneous), which is not necessarily the 
case with raw data from the local area network. The 
data preparation component receives information 
from either the operational environment or training 
tapes and performs three functions: (a) collects the 
information required by the expert system, (b) 
performs any additional computations required on the 
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data, and (c) filters and transforms that data into a 
form suitable for the expert system. Non-discrete 
numeric data are compared to thresholds and 
converted to "symbolic" forms whenever possible. 

The fact assertion component takes the prepared data 
and puts that required by the expert system into the 
expert system fact base and the remaining data into 
the C software environment for background 
processing and reference. The monitoring component 
generates intermediate conclusions and statuses of 
the individual subsystems ONAV observes and 
manages. The analysis component performs an 
overall assessment of the current situation taking into 
account interrelationships between subsystems. The 
output component controls the sending of notices 
and/or recommendations to the ONAV expert system 
console. 

CURRENT PROGRESS AND FUTURE PLANS 

The ENTRY ONAV prototype was completed in June 
87. A complete version of the ENTRY knowledge 
base design is currently under development. The 
ENTRY knowledge base line document was also 
completed and is waiting for final publication. The 
RENDEZVOUS ONAV is also well under way, a set of 
nominal rules are written and currently under design 
evaluation. Development work on the ascent phases 
of ONAV was initiated in July. 
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